I'm still unable to get the Transportorga to actually transport patients, but other than that I can say I'm happy with the changes in this PR.

The Benötigte Fahrzeuge information is not available for B-Rooms that are targets for vehicle requests by e.g. a PA, despite this being logical and exactly what the note in the UI says about it (Benötigte Fahrzeuge um alle Patienten zu behandeln (PA) oder Anfragen zu erfüllen (B-Raum)).

We have already discussed this here and moved it to #1102. Since a reliable bugfix also needs #1094 fixed (for details, see my comment at the first issue), I would refrain from fixing it here and making this PR even larger.

Do you think it makes sense to adjust the description text in the UI as long as this information is not available on staging areas?

The Benötigte Fahrzeuge information is not available for B-Rooms that are targets for vehicle requests by e.g. a PA, despite this being logical and exactly what the note in the UI says about it (Benötigte Fahrzeuge um alle Patienten zu behandeln (PA) oder Anfragen zu erfüllen (B-Raum)).

We have already discussed this here and moved it to #1102. Since a reliable bugfix also needs #1094 fixed (for details, see my comment at the first issue), I would refrain from fixing it here and making this PR even larger.

Do you think it makes sense to adjust the description text in the UI as long as this information is not available on staging areas?

Oops, sorry. Yes, probably a good idea to add a note in UI there if I have noticed it for a second time now ^^

I've just noticed that the Akzeptieren and Ablehnen buttons of the vehicle-request message don't have shortcuts associated with them.

Do you have a suggestion for what hotkeys to use? I would like to have something that does not conflict with other hotkeys, so that the IFS can for example switch to the staging area and ask for the number of vehicles available while the request is still open, so a simple Enter and Esc would not be possible.

I think the only option would be either F-keys or some combinations with Ctrl and/or Alt, if we still want to keep those buttons separate from the "Fertig" button.

Alternatively, I could remove the additional "Akzeptieren"/"Ablehnen" buttons and open a modal after "Fertig" was clicked. To make it clear that this radiogram needs additional information to complete it, the button could be renamed (e.g. "Antwort senden") and/or have a different color (e.g. yellow) in these cases. However, this would obviously need two key presses or button clicks (open modal, send answer) and would also require some bigger changes in the code, as the radiogram content (with the accept/deny buttons) is plugged into the frame with the done button, without the frame knowing whether there are additional actions inside.

[…]

Oops, sorry. Yes, probably a good idea to add a note in UI there if I have noticed it for a second time now ^^

Temporarily removed staging area in 58ef848

I've just noticed that the Akzeptieren and Ablehnen buttons of the vehicle-request message don't have shortcuts associated with them.

Do you have a suggestion for what hotkeys to use? I would like to have something that does not conflict with other hotkeys, so that the IFS can for example switch to the staging area and ask for the number of vehicles available while the request is still open, so a simple Enter and Esc would not be possible.

I think the only option would be either F-keys or some combinations with Ctrl and/or Alt, if we still want to keep those buttons separate from the "Fertig" button.

What about j and n for ja and nein, respectively? This should be unambiguous in the application and be somewhat logical without being too easy to do by accident, I think. Ah, I should've looked more closely, j is actually used and n is only two more information requests away from also being used. y and n for yes and no would work at the moment.

Otherwise, maybe Ctrl + Enter and Ctrl + Esc or Ctrl + Backspace? Ctrl + Esc is a little weird to hit on a normal keyboard. On the other hand, Backspace and Enter are right next to each other and could be mistakenly clicked.

With Ctrl we should look at how this gets handled on macOS with their Command key. Are there already shortcuts using Ctrl? I didn't find any.

Alternatively, I could remove the additional "Akzeptieren"/"Ablehnen" buttons and open a modal after "Fertig" was clicked. To make it clear that this radiogram needs additional information to complete it, the button could be renamed (e.g. "Antwort senden") and/or have a different color (e.g. yellow) in these cases. However, this would obviously need two key presses or button clicks (open modal, send answer) and would also require some bigger changes in the code, as the radiogram content (with the accept/deny buttons) is plugged into the frame with the done button, without the frame knowing whether there are additional actions inside.

I don't think shortcuts for two buttons warrant such massive changes.

I'm still unable to get the Transportorga to actually transport patients, but other than that I can say I'm happy with the changes in this PR.

I've investigated this again and now found two issues:

1. The TO behavior does not manage its own region by default (as this would only make sense for TO behaviors added to patient trays, not for standalone TO regions). However, the TO region selector did not allow to add the own region. I've now fixed this in 590c629
2. The TO needs a source for vehicles. Unfortunately, this mechanism is (1) separate from the resource request behavior we know from patient trays or staging areas, (2) unset by default, and (3) cannot be set from the IFS UI. As a quick fix, I've added a dedicated command to set the source in d525b46. An approach for a thorough solution is outlined in Unify vehicle requests between requestBehavior and managePatientTransportToHospitalBehavior #1110

What about j and n for ja and nein, respectively? This should be unambiguous in the application and be somewhat logical without being too easy to do by accident, I think. Ah, I should've looked more closely, j is actually used and n is only two more information requests away from also being used. y and n for yes and no would work at the moment.

I'd rather not use single letters (or numbers) to not run into issues with future information requests or commands.

Otherwise, maybe Ctrl + Enter and Ctrl + Esc or Ctrl + Backspace? Ctrl + Esc is a little weird to hit on a normal keyboard. On the other hand, Backspace and Enter are right next to each other and could be mistakenly clicked.

With Ctrl we should look at how this gets handled on macOS with their Command key. Are there already shortcuts using Ctrl? I didn't find any.

No, there are no shortcuts using Ctrl yet and I would also not be able to test them on macOS systems, that's a fair point to consider.

What do you think about just using + (accept) and - (deny)? This does not need any combinations and should remain collision-free on the main modal (additional popups or modals deactivate all underlying hotkeys anyways)

[...]

I'd rather not use single letters (or numbers) to not run into issues with future information requests or commands.

Fair point.

[...]

No, there are no shortcuts using Ctrl yet and I would also not be able to test them on macOS systems, that's a fair point to consider.

Yes, me neither. I could ask some people with Macbooks to test it for me but this would be quite cumbersome.

What do you think about just using + (accept) and - (deny)? This does not need any combinations and should remain collision-free on the main modal (additional popups or modals deactivate all underlying hotkeys anyways)

+ and - sound good!

No, there are no shortcuts using Ctrl yet and I would also not be able to test them on macOS systems, that's a fair point to consider.

I have a MacBook that I could use to test or or bring to HPI for your testing.

I now went for + and - (implemented in 5bb7417).

Thus, there is also no urgent need to test hotkeys on macOS, but I'll keep in in mind to test if we see each other anyways.

@ClFeSc if I didn't miss anything, all of your change requests and suggestions should now be addressed.

There aren't any test scenarios. Is this intended? If not, please add them, otherwise I'm happy with the changes and think we can merge.

There are test scenarios: hpi-sam/fuesim-digital-public-test-scenarios#17. But thx for the reminder. I want the submodule to always point to the commit on the main branch, so I cannot update it until the scenario PR is merged.

Let me quickly check if there have been any changes to the models during the review process (iirc, I actually changed a property name) and update the scenarios if necessary

Okay, the only change was 2623a06, but I did this change before creating the test scenarios, so they're still up-to-date.